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Analysis of the 64-bit Boundary in IPv6 Addressing 


Abstract 


The IPv6 unicast addressing format includes a separation between the 
prefix used to route packets to a subnet and the interface identifier 
used to specify a given interface connected to that subnet. 
Currently, the interface identifier is defined as 64 bits long for 
almost every case, leaving 64 bits for the subnet prefix. This 
document describes the advantages of this fixed boundary and analyzes 
the issues that would be involved in treating it as a variable 
boundary. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7421. 
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1. Introduction 


Rather than simply overcoming the IPv4 address shortage by doubling 
the address size to 64 bits, IPv6 addresses were originally chosen to 
be 128 bits long to provide flexibility and new possibilities. In 
particular, the notion of a well-defined interface identifier was 
added to the IP addressing model. The IPv6 addressing architecture 
[RFC4291] specifies that a unicast address is divided into n bits of 
subnet prefix followed by (128-n) bits of interface identifier (IID). 
The bits in the IID may have significance only in the process of 
deriving the IID; once it is derived, the entire identifier should be 
treated as an opaque value [RFC7136]. Also, since IPv6 routing is 
entirely based on variable length prefixes (also known as variable 
length subnet masks), there is no basic architectural assumption that 
n has any particular fixed value. All IPv6 routing protocols support 
prefixes of any length up to /128. 


The IID is of basic importance in the IPv6 stateless address 
autoconfiguration (SLAAC) process [RFC4862]. However, it is 
important to understand that its length is a parameter in the SLAAC 
process, and it is determined in a separate link-type specific 
document (see the definition of "interface identifier" in Section 2 
of RFC 4862). The SLAAC protocol does not define its length or 
assume any particular length. Similarly, DHCPv6 [RFC3315] does not 
include a prefix length in its address assignment. 


The notion of a /64 boundary in the address was introduced after the 
initial design of IPv6, following a period when it was expected to be 
at /80. There were two motivations for setting it at /64. One was 
the original "8-8" proposal [ODELL] that eventually led to the 
Identifier-Locator Network Protocol (ILNP) [RFC6741], which required 
a fixed point for the split between local and wide-area parts of the 
address. The other was the expectation that 64-bit Extended Unique 
Identifier (EUI-64) Media Access Control (MAC) addresses would become 
widespread in place of 48-bit addresses, coupled with the plan at 
that time that auto-configured addresses would normally be based on 
interface identifiers derived from MAC addresses. 


As a result, RFC 4291 describes a method of forming interface 
identifiers from IEEE EUI-64 hardware addresses [IEEE802], and this 
specifies that such interface identifiers are 64 bits long. Various 
other methods of forming interface identifiers also specify a length 
of 64 bits. The addressing architecture, as modified by [RFC7136], 
states that: 
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For all unicast addresses, except those that start with the binary 
value 000, Interface IDs are required to be 64 bits long. If 
derived from an IEEE MAC-layer address, they must be constructed 
in Modified EUI-64 format. 


The de facto length of almost all IPv6 interface identifiers is 
therefore 64 bits. The only documented exception is in [RFC6164], 
which standardizes 127-bit prefixes for point-to-point links between 
routers, among other things, to avoid a loop condition known as the 
ping-pong problem. 


With that exception, and despite the comments above about the routing 
architecture and the design of SLAAC, using an IID shorter than 64 
bits and a subnet prefix longer than 64 bits is outside the current 
IPv6 specifications, so results may vary. 


The question is often asked why the subnet prefix boundary is set 
rigidly at /64. The first purpose of this document is to explain the 
advantages of the fixed IID length. Its second purpose is to 
analyze, in some detail, the effects of hypothetically varying the 
IID length. The fixed-length limits the practical length of a 
routing prefix to 64 bits, whereas architecturally, and from the 
point of view of routing protocols, it could be any value up to /128, 
as in the case of host routes. Whatever the length of the IID, the 
longest match is done on the concatenation of prefix and IID. Here, 
we mainly discuss the question of a shorter IID, which would allow a 
longer subnet prefix. The document makes no proposal for a change to 
the IID length. 


The following three sections describe, in turn, the advantages of the 
fixed-length IID, some arguments for shorter lengths, and the 
expected effects of varying the length. 


2. Advantages of a Fixed Identifier Length 


As mentioned in Section 1, the existence of an IID of a given length 
is a necessary part of IPv6 stateless address autoconfiguration 
(SLAAC) [RFC4862]. This length is normally the same for all nodes on 
a given link that is running SLAAC. Even though this length is a 
parameter for SLAAC, determined separately for the link-layer media 
type of each interface, a globally fixed IID length for all link- 
layer media is the simplest solution and is consistent with the 
principles of Internet host configuration described in [RFC5505]. 


An interface identifier of significant length, clearly separated from 
the subnet prefix, makes it possible to limit the traceability of a 
host computer by varying the identifier. This is discussed further 
in Section 4.5. 


Carpenter, et al. Informational [Page 4] 


RFC 7421 Why 64 January 2015 


An interface identifier of significant length guarantees that there 

are always enough addresses in any subnet to add one or more real or 
virtual interfaces. There might be other limits, but IP addressing 

will never get in the way. 


The addressing architecture [RFC4291] [RFC7136] sets the IID length 
at 64 bits for all unicast addresses and therefore for all media 
supporting SLAAC. An immediate effect of fixing the IID length at 64 
bits is, of course, that it fixes the subnet prefix length also at 64 
bits, regardless of the aggregate prefix assigned to the site 
concerned, which in accordance with [RFC6177] should be /56 or 
shorter. This situation has various specific advantages: 


o Everything is the same. Compared to IPv4, there is no more 
calculating leaf subnet sizes, no more juggling between subnets, 
and fewer consequent errors. Network design is therefore simpler 
and much more straightforward. This is of importance for all 


types of networks -- enterprise, campus, small office, or home 
networks -- and for all types of operator, from professional to 
consumer. 

o Adding a subnet is easy -- just take another /64 from the pool. 


No estimates, calculations, consideration, or judgement is needed. 
o Router configurations are homogeneous and easier to understand. 


o Documentation is easier to write and easier to read; training is 
easier. 


The remainder of this document describes arguments that have been 
made against the current fixed IID length and analyzes the effects of 
a possible change. However, the consensus of the IETF is that the 
benefits of keeping the length fixed at 64 bits and the practical 
difficulties of changing it outweigh the arguments for change. 


3. Arguments for Shorter Identifier Lengths 


In this section, we describe arguments for scenarios where shorter 
IIDs, implying prefixes longer than /64, have been used or proposed. 


3.1. Insufficient Address Space Delegated 


A site may not be delegated a sufficiently generous prefix from which 
to allocate a /64 prefix to all of its internal subnets. In this 
case, the site may either determine that it does not have enough 
address space to number all its network elements and thus, at the 
very best, be only partially operational, or it may choose to use 
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internal prefixes longer than /64 to allow multiple subnets and the 
hosts within them to be configured with addresses. 


In this case, the site might choose, for example, to use a /80 per 
subnet in combination with hosts using either manually configured 
addressing or DHCPv6 [RFC3315]. 


Scenarios that have been suggested where an insufficient prefix might 
be delegated include home or small office networks, vehicles, 
building services, and transportation services (e.g., road signs). 

It should be noted that the homenet architecture text [RFC7368] 
states that Customer Premises Equipment (CPE) should consider the 
lack of sufficient address space to be an error condition, rather 
than using prefixes longer than /64 internally. 


Another scenario occasionally suggested is one where the Internet 
address registries actually begin to run out of IPv6 prefix space, 
such that operators can no longer assign reasonable prefixes to users 
in accordance with [RFC6177]. It is sometimes suggested that 
assigning a prefix such as /48 or /56 to every user site (including 
the smallest) as recommended by [RFC6177] is wasteful. In fact, the 
currently released unicast address space, 2000::/3, contains 35 
trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a 
small fraction have been allocated. Allowing for a conservative 
estimate of allocation efficiency, i.e., an HD-ratio of 0.94 
[RFC4692], approximately 5 trillion /48 prefixes can be allocated. 
Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 
prefixes can be allocated. Furthermore, with only 2000::/3 currently 
committed for unicast addressing, we still have approximately 85$ of 
the address space in reserve. Thus, there is no objective risk of 
prefix depletion by assigning /48 or /56 prefixes even to the 
smallest sites. 


3.2. Hierarchical Addressing 


Some operators have argued that more prefix bits are needed to allow 
an aggregated hierarchical addressing scheme within a campus or 
corporate network. However, if a campus or enterprise gets a /48 
prefix (or shorter), then that already provides 16 bits for 


hierarchical allocation. In any case, flat IGP routing is widely and 
successfully used within rather large networks, with hundreds of 
routers and thousands of end systems. Therefore, there is no 


objective need for additional prefix bits to support hierarchy and 
aggregation within enterprises. 
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3.3. Audit Requirement 


Some network operators wish to know and audit nodes that are active 
on a network, especially those that are allowed to communicate off- 
link or off-site. They may also wish to limit the total number of 
active addresses and sessions that can be sourced from a particular 
host, LAN, or site, in order to prevent potential resource-depletion 
attacks or other problems spreading beyond a certain scope of 
control. It has been argued that this type of control would be 
easier if only long network prefixes with relatively small numbers of 
possible hosts per network were used, reducing the discovery problem. 
However, such sites most typically operate using DHCPv6, which means 
that all legitimate hosts are automatically known to the DHCPv6 
servers, which is sufficient for audit purposes. Such hosts could, 
if desired, be limited to a small range of IID values without 
changing the /64 subnet length. Any hosts inadvertently obtaining 
addresses via SLAAC can be audited through Neighbor Discovery (ND) 
logs. 


3.4. Concerns over ND Cache Exhaustion 


A site may be concerned that it is open to ND cache exhaustion 
attacks [RFC3756], whereby an attacker sends a large number of 
messages in rapid succession to a series of (most likely inactive) 
host addresses within a specific subnet. Such an attack attempts to 
fill a router's ND cache with ND requests pending completion, which 
results in denying correct operation to active devices on the 
network. 


One potential way to mitigate this attack would be to consider using 
a /120 prefix, thus limiting the number of addresses in the subnet to 
be similar to an IPv4 /24 prefix, which should not cause any concerns 
for ND cache exhaustion. Note that the prefix does need to be quite 
long for this scenario to be valid. The number of theoretically 
possible ND cache slots on the segment needs to be of the same order 
of magnitude as the actual number of hosts. Thus, small increases 
from the /64 prefix length do not have a noticeable impact; even 2^32 
potential entries, a factor of two billion decrease compared to 2%64, 
is still more than enough to exhaust the memory on current routers. 
Given that most link-layer mappings cause SLAAC to assume a 64-bit 
network boundary, in such an approach hosts would likely need to use 
DHCPv6 or be manually configured with addresses. 


It should be noted that several other mitigations of the ND cache 

attack are described in [RFC6583], and that limiting the size of the 
cache and the number of incomplete entries allowed would also defeat 
the attack. For the specific case of a point-to-point link between 
routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. 
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4. Effects of Varying the Interface Identifier Length 


This section of the document analyzes the impact and effects of 
varying the length of an IPv6 unicast IID by reducing it to less than 
64 bits. 


4.1. Interaction with IPv6 Specifications 


The precise 64-bit length of the IID is widely mentioned in numerous 
RFCs describing various aspects of IPv6. It is not straightforward 
to distinguish cases where this has normative impact or affects 
interoperability. This section aims to identify specifications that 
contain an explicit reference to the 64-bit length. Regardless of 
implementation issues, the RFCs themselves would all need to be 
updated if the 64-bit rule was changed, even if the updates were 
small, which would involve considerable time and effort. 


First and foremost, the RFCs describing the architectural aspects of 
IPv6 addressing explicitly state, refer, and repeat this apparently 
immutable value: Addressing Architecture [RFC4291], IPv6 Address 
Assignment to End Sites [RFC6177], Reserved IIDs [RFC5453], and ILNP 
Node Identifiers [RFC6741]. Customer edge routers impose /64 for 
their interfaces [RFC7084]. The IPv6 Subnet Model [RFC5942] points 
out that the assumption of a /64 prefix length is a potential 
implementation error. 


Numerous IPv6-over-foo documents make mandatory statements with 
respect to the 64-bit length of the IID to be used during the 
Stateless Autoconfiguration. These documents include [RFC2464] 
(Ethernet), [RFC2467] (Fiber Distributed Data Interface (FDDI)), 
[RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet), 
[RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre 
Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121] 
[RFC5692] (IEEE 802.16), [RFC2529] (6o0ver4), [RFC5214] (Intra-Site 
Automatic Tunnel Addressing Protocol (ISATAP)), [AERO-TRANS] 
(Asymmetric Extended Route Optimization (AERO)), [BLUETOOTH-LE] 
(BLUETOOTH Low Energy), [IPv6-TRANS] (IPv6 over MS/TP), and 
[IPv6-G9959] (IPv6 packets over ITU-T G.9959). 


To a lesser extent, the address configuration RFCs themselves may in 
Some ways assume the 64-bit length of an IID (e.g, RFC 4862 for the 
link-local addresses, DHCPv6 for the potentially assigned EUI- 
64-based IP addresses, and Optimistic Duplicate Address Detection 
[RFC4429] that computes 64-bit-based collision probabilities). 


The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and 


MLDv2 [RFC3810] protocols mandate that all queries be sent with a 
link-local source address, with the exception of MLD messages sent 
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using the unspecified address when the link-local address is 
tentative [RFC3590]. At the time of publication of RFC 2710, the 
IPv6 addressing architecture specified link-local addresses with 
64-bit interface identifiers.  MLDv2 explicitly specifies the use of 
the fe80::/64 link-local prefix and bases the querier election 
algorithm on the link-local subnet prefix of length /64. 


The "IPv6 Flow Label Specification" [RFC6437] gives an example of a 
20-bit hash function generation, which relies on splitting an IPv6 
address in two equally sized, 64-bit-length parts. 


The basic transition mechanisms [RFC4213] refer to IIDs of length 64 
for link-local addresses; other transition mechanisms such as Teredo 
[RFC4380] assume the use of IIDs of length 64. Similar assumptions 
are found in 6to4 [RFC3056] and 6rd [RFC5969]. Translation-based 
transition mechanisms such as NAT64 and NPTv6 have some dependency on 
prefix length, discussed below. 


The proposed method [RFC7278] of extending an assigned /64 prefix 
from a smartphone's cellular interface to its WiFi link relies on 
prefix length, and implicitly on the length of the IID, to be valued 
at 64. 


The Cryptographically Generated Addresses (CGA) and Hash-Based 
Addresses (HBA) specifications rely on the 64-bit identifier length 
(see below), as do the Privacy extensions [RFC4941] and some examples 
in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296]. 


464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. 
However, it also discusses the possibility of using the interface 
address on the device as the end point for the traffic, thus 
potentially removing this dependency. 


[RFC2526] reserves a number of subnet anycast addresses by reserving 
Some anycast IIDs. An anycast IID so reserved cannot be less than 7 
bits long. This means that a subnet prefix length longer than /121 
is not possible, and a subnet of exactly /121 would be useless since 
all its identifiers are reserved. It also means that half of a /120 
is reserved for anycast. This could of course be fixed in the way 
described for /127 in [RFC6164], i.e., avoiding the use of anycast 
within a /120 subnet. Note that support for "on-link anycast" is a 
standard IPv6 neighbor discovery capability [RFC4861] [RFC7094]; 
therefore, applications and their developers would expect it to be 
available. 


The Mobile IP home network models [RFC4887] rely heavily on the /64 
subnet length and assume a 64-bit IID. 
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While preparing this document, it was noted that many other IPv6 
Specifications refer to mandatory alignment on 64-bit boundaries, 
64-bit data structures, 64-bit counters in MIBs, 64-bit sequence 
numbers and cookies in security, etc. Finally, the number "64" may 
be considered "magic" in some RFCs, e.g., 64k limits in DNS and 
Base64 encodings in MIME. None of this has any influence on the 
length of the IID but might confuse a careless reader. 


4.2. Possible Failure Modes 


This section discusses several specific aspects of IPv6 where we can 
expect operational failures with subnet prefixes other than /64. 


o Router implementations: Router implementors might interpret IETF 
specifications such as [RFC6164] and [RFC7136] as indicating that 
prefixes between /65 and /126 (inclusive) for unicast packets on- 
the-wire are invalid and that operational practices that utilize 
prefix lengths in this range may fail on some devices, as 
discussed in Section 4.3.2. 


o Multicast: [RFC3306] defines a method for generating IPv6 
multicast group addresses based on unicast prefixes. This method 
assumes a longest prefix of 64 bits. If a longer prefix is used, 
there is no way to generate a specific multicast group address 
using this method. In such cases, the administrator would need to 
use an "artificial" prefix from within their allocation (a /64 or 
shorter) from which to generate the group address. This prefix 
would not correspond to a real subnet. 


Similarly, [RFC3956], which specifies the Embedded Rendezvous 
Point (RP)) allowing IPv6 multicast rendezvous point addresses to 
be embedded in the multicast group address, would also fail, as 
the scheme assumes a maximum prefix length of 64 bits. 


o CGA: The Cryptographically Generated Address format [RFC3972] is 
heavily based on a /64 interface identifier. [RFC3972] has 
defined a detailed algorithm showing how to generate a 64-bit 
interface identifier from a public key and a 64-bit subnet prefix. 
Changing the /64 boundary would certainly invalidate the current 
CGA definition. However, the CGA might benefit in a redefined 
version if more bits are used for interface identifiers (which 
means shorter prefix length). For now, 59 bits are used for 
cryptographic purposes. The more bits are available, the stronger 
CGA could be. Conversely, longer prefixes would weaken CGA. 


o NAT64: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] 
are flexible for the prefix length.  [RFC6052] has defined 
multiple address formats for NAT64. In Section 2 of 
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"IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the 
network-specific prefix could be one of /32, /40, /48, /56, /64, 
and /96. The remaining part of the IPv6 address is constructed by 
a 32-bit IPv4 address, an 8-bit u byte and a variable length 
suffix (there is no u byte and suffix in the case of the 96-bit 
Well-Known Prefix).  NAT64 is therefore OK with a subnet boundary 
out to /96 but not longer. 


o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also 
bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 
prefix. When the NPTv6 Translator is configured with a /48 or 
shorter prefix, the 64-bit interface identifier is kept unmodified 
during translation. However, the /64 boundary might be changed as 
long as the "inside" and "outside" prefixes have the same length. 


o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is 
designed around the /64 boundary, since it relies on locally 
unique 64-bit node identifiers (in the interface identifier 
field). While a redesign to use longer prefixes is not 
inconceivable, this would need major changes to the existing 
Specification for the IPv6 version of ILNP. 


o Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in 
its insecure form treats IPv6 addresses as opaque 128-bit objects. 
However, to secure the protocol against spoofing, it is essential 
to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs 
are generated using a procedure that assumes a 64-bit identifier. 
Therefore, in effect, secure shim6 is affected by the /64 boundary 
exactly like CGAs. 


o Duplicate address risk: If SLAAC was modified to work with shorter 
IIDs, the statistical risk of hosts choosing the same pseudo- 
random identifier [RFC7217] would increase correspondingly. The 
practical impact of this would range from slight to dramatic, 
depending on how much the IID length was reduced. In particular, 
a /120 prefix would imply an 8-bit IID and address collisions 
would be highly probable. 


o The link-local prefix: While RFC 4862 is careful not to define any 
specific length of link-local prefix within fe80::/10, the 
addressing architecture [RFC4291] does define the link-local IID 
length to be 64 bits. If different hosts on a link used IIDs of 
different lengths to form a link-local address, there is potential 
for confusion and unpredictable results. Typically today the 
choice of 64 bits for the link-local IID length is hard-coded per 
interface, in accordance with the relevant IPv6-over-foo 
Specification, and systems behave as if the link-local prefix was 
actually fe80::/64. There might be no way to change this except 


Carpenter, et al. Informational [Page 11] 


RFC 7421 Why 64 January 2015 


conceivably by manual configuration, which will be impossible if 
the host concerned has no local user interface. 


It goes without saying that if prefixes longer than /64 are to be 
used, all hosts must be capable of generating IIDs shorter than 64 
bits, in order to follow the auto-configuration procedure correctly 


[RFC4862]. 
4.3. Experimental Observations 
4.3.1. Survey of the processing of Neighbor Discovery Options with 


Prefixes Other than /64 


This section provides a survey of the processing of Neighbor 
Discovery options that include prefixes that are different than /64. 


The behavior of nodes was assessed with respect to the following 
options: 


o PIO-A: Prefix Information Option (PIO) [RFC4861] with the A bit 
set. 


o PIO-L: Prefix Information Option (PIO) [RFC4861] with the L bit 
set. 


o PIO-AL: Prefix Information Option (PIO) [RFC4861] with both the A 
and L bits set. 


o RIO: Route Information Option (RIO) [RFC4191]. 
In the tables below, the following notation is used: 
NOT-SUP: 
This option is not supported (i.e., it is ignored no matter the 


prefix length used). 


LOCAL: 
The corresponding prefix is considered "on-link". 


ROUTE: 
The corresponding route is added to the IPv6 routing table. 


NOT-DEF: 
The default configuration is NOT-SUP, but there is an option to 
enable ROUTE. 


IGNORE: 
The option is ignored as an error. 
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4R-------------------- 4R-------- 4R------- 4R-------- 4R--------- * 
| Operating System | PIO-A | PIO-L | PIO-AL | RIO | 
4R-------------------- 4R-------- 4+------- 4+-------- 4+--------- + 
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| OpenBSD-current | IGNORE | LOCAL | LOCAL | Nor-suP | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | 
4-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 


Table 1: Processing of ND options with prefixes longer than /64 


4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| Operating System | PIO-A | PIO-L | PIO-AL | RIO | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| | Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF | 
4R--------2--------2---- 4R-------- 4+------- 4+-------- 4+--------- + 
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP | 
4R-------------------- 4R-------- 4R------- 4R-------- 4R--------- * 
| OpenBSD-current | IGNORE | LOCAL | LOCAL | Nor-suP | 
4R-------------------- 4R-------- 4+------- 4+-------- 4+--------- + 
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | 
+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | 
4+-------------------- 4+-------- 4+------- 4+-------- 4+--------- + 


Table 2: Processing of ND options with prefixes shorter than /64 
The results obtained can be summarized as follows: 
o The "A" bit in the Prefix Information Options is honored only if 
the prefix length is 64. This is consistent with [RFC4862], at 


least for the case where the IID length is defined to be 64 bits 
in the corresponding link-type-specific document, which is the 
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case for all currently published such documents. [RFC4862] 
defines the case where the sum of the advertised prefix length and 
the IID length does not equal 128 as an error condition. 


o The "L" bit in the Prefix Information Options is honored for any 
arbitrary prefix length (whether shorter or longer than /64). 


o Nodes that support the Route Information Option allow such routes 
to be specified with prefixes of any arbitrary length (whether 
shorter or longer than /64) 


4.3.2. Other Observations 


Participants in the V6OPS working group have indicated that some 
forwarding devices have been shown to work correctly with long 
prefixes such as /80 or /96. Indeed, it is to be expected that 
forwarding based on the longest prefix match will work for any prefix 
length, and no reports of this completely failing have been noted. 
Also, DHCPv6 is in widespread use without any dependency on the /64 
boundary.  Reportedly, there are deployments of /120 subnets 
configured using DHCPv6. 


There have been definite reports that some routers have a performance 
drop-off or even resource exhaustion for prefixes longer than /64 due 
to design issues. In particular, some routing chip designs allocate 
much less space for longer prefixes than for prefixes up to /64 for 
the sake of savings in memory, power, and lookup latency. Some 
devices need special-case code to handle point-to-point links 
according to [RFC6164]. 


It has been reported that at least one type of switch has a content- 
addressable memory limited to 144 bits, which is indeed a typical 
value for commodity components [TCAM]. This means that packet 
filters or access control lists cannot be defined based on 128-bit 
addresses and two 16-bit port numbers; the longest prefix that could 
be used in such a filter is a /112. 


4.4. Implementation and Deployment Issues 


From an early stage, implementations and deployments of IPv6 assumed 
the /64 subnet length, even though routing was based on prefixes of 
any length. As shown above, this became anchored in many 
Specifications (Section 4.1) and in important aspects of 
implementations commonly used in local area networks (Section 4.3). 
In fact, a programmer might be lulled into assuming a comfortable 
rule of thumb that subnet prefixes are always /64 and an IID is 
always of length 64. Apart from the limited evidence in 

Section 4.3.1, we cannot tell without code inspections or tests 
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whether existing stacks are able to handle a flexible IID length or 
whether they would require modification to do so. A conforming 
implementation of an IPv6-over-foo that specifies a 64 bit IID for 
foo links will of course only support 64. But in a well designed 
Stack, the IP layer itself will treat that 64 as a parameter, so 
changing the IID length in the IPv6-over-foo code should be all that 
is necessary. 


The main practical consequence of the existing specifications is that 
deployments in which longer subnet prefixes are used cannot make use 
of SLAAC-configured addresses and require either manually configured 
addresses or DHCPv6. To reverse this argument, if it was considered 
desirable to allow auto-configured addresses with subnet prefixes 
longer than /64, all of the specifications identified above as 
depending on /64 would have to be modified with due regard to 
interoperability with unmodified stacks. In fact, [RFC7217] allows 
for this possibility. Then, modified stacks would have to be 
developed and deployed. It might be the case that some stacks 
contain dependencies on the /64 boundary that are not directly 
implied by the specifications, and any such hidden dependencies would 
also need to be found and removed. 


At least one DHCPv6 client unconditionally installs a /64 prefix as 
on-link when it configures an interface with an address, although 
some specific operating system vendors seem to change this default 
behavior by tweaking a client-side script. This is in clear 
violation of the IPv6 subnet model [RFC5942]. The motivation for 
this choice is that if there is no router on the link, the hosts 
would fail to communicate with each other using the configured 
addresses because the "on-link assumption" was removed in [RFC4861]. 
This is not really about the magic number of 64, but an 
implementation may sometimes pick an arbitrary value of prefix length 
due to the removal of the on-link assumption, and the value chosen 
will most likely be 64. 


Typical IP Address Management (IPAM) tools treat /64 as the default 
subnet length but allow users to specify longer subnet prefixes if 
desired. Clearly, all IPAM tools and network management systems 
would need to be checked in detail. 


Finally, IPv6 is already deployed at many sites, with a large number 
of staff trained on the basis of the existing standards, supported by 
documentation and tools based on those standards. Numerous existing 
middlebox devices are also based on those standards. These people, 
documents, tools, and devices represent a very large investment that 
would be seriously impacted by a change in the /64 boundary. 
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4.5. Privacy Issues 


The length of the interface identifier has implications for privacy 
[ADDRESS-PRIVACY]. In any case in which the value of the identifier 
is intended to be hard to guess, whether or not it is 
cryptographically generated, it is apparent that more bits are 
better. For example, if there are only 20 bits to be guessed, then 
at most just over a million guesses are needed, which is well within 
the capacity of a low-cost attack mechanism. It is hard to state in 
general how many bits are enough to protect privacy, since this 
depends on the resources available to the attacker, but it seems 
clear that a privacy solution needs to resist an attack requiring 
billions rather than millions of guesses.  Trillions would be better, 
suggesting that at least 40 bits should be available. Thus, we can 
argue that subnet prefixes longer than say /80 might raise privacy 
concerns by making the IID guessable. 


A prefix long enough to limit the number of addresses comparably to 
an IPv4 subnet, such as /120, would create exactly the same situation 
for privacy as IPv4 except for the absence of NAT. In particular, a 
host would be forced to pick a new IID when roaming to a new network 
to avoid collisions. As mentioned earlier, it is likely that SLAAC 
will not be used on such a subnet. 


5. Security Considerations 
In addition to the privacy issues mentioned in Section 4.5 and the 


issues mentioned with CGAs and HBAs in Section 4.2, the length of the 
subnet prefix affects the matter of defense against scanning attacks 


[HOST-SCANNING]. Assuming the attacker has discovered or guessed the 
prefix length, a longer prefix reduces the space that the attacker 
needs to scan, e.g., to only 256 addresses if the prefix is /120. On 


the other hand, if the attacker has not discovered the prefix length 
and assumes it to be /64, routers can trivially discard attack 
packets that do not fall within an actual subnet. 


However, assume that an attacker finds one valid address "A" and 
assumes that it is within a long prefix such as a /120. The attacker 
then starts a scanning attack by scanning "outwards" from A, by 
trying A+1, A-1, A-*2, A-2, etc. This attacker will easily find all 
hosts in any subnet with a long prefix, because they will have 
addresses close to A. We therefore conclude that any prefix 
containing densely packed valid addresses is vulnerable to a scanning 
attack, without the attacker needing to guess the prefix length. 
Therefore, to preserve IPv6's advantage over IPv4 in resisting 
Scanning attacks, it is important that subnet prefixes are short 
enough to allow sparse allocation of identifiers within each subnet. 
The considerations are similar to those for privacy, and we can again 


Carpenter, et al. Informational [Page 16] 


RFC 7421 Why 64 January 2015 


6. 


6. 


argue that prefixes longer than say /80 might significantly increase 
vulnerability.  Ironically, this argument is exactly converse to the 
argument for longer prefixes to resist an ND cache attack, as 
described in Section 3.4. 


Denial-of-service attacks related to Neighbor Discovery are discussed 
in Section 3.4 and in [RFC6583]. One of the mitigations suggested by 
that document is "sizing subnets to reflect the number of addresses 
actually in use", but the fact that this greatly simplifies scanning 
attacks is not noted. For further discussion of scanning attacks, 
see [HOST-SCANNING]. 


Note that, although not known at the time of writing, there might be 
other resource exhaustion attacks available, similar in nature to the 
ND cache attack. We cannot exclude that such attacks might be 
exacerbated by sparsely populated subnets such as a /64. It should 
also be noted that this analysis assumes a conventional deployment 
model with a significant number of end-systems located in a single 
LAN broadcast domain. Other deployment models might lead to 
different conclusions. 
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